Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add initial CoreCLR compilation support for Apple Silicon #40435

Merged
merged 100 commits into from
Oct 8, 2020

Conversation

sdmaclea
Copy link
Contributor

@sdmaclea sdmaclea commented Aug 6, 2020

Add initial CoreCLR compilation support for Apple Silicon

Initial draft of CoreCLR runtime native code to support Apple Silicon

Fixes native runtime compilation issues
Draft implementation
Testing limited to compilation on Apple

Does not fix Arm64 ABI issues
Does not Prototypes fix write no execute issues

Fixes #40149

Initial draft of CoreCLR runtime native code to supprt  Apple Silicon

Fixes native runtime compitation issues
Draft implementation
Testing linited to compilation on Apple

Does not fix Arm64 ABI issues
Does not fix write no execute issues
@sdmaclea
Copy link
Contributor Author

sdmaclea commented Aug 6, 2020

Status:

  • src/coreclr/build-runtime.sh succeeds on MacOS-arm64
  • This shouldn't merge with master branch due to risk to 5.0. (This is the reason the PR is marked draft).
  • Need to run CI to see if this causes 5.0 regression.

I would appreciate eyes on this. It hasn't been tested yet, but anything we find in code review will simplify bring-up.

/cc @tommcdon @JulieLeeMSFT @mangod9 @noahfalk

I think this unblocks the JIT team.

.long 0x04000000 // DWARF
.quad 0
.quad 0
#endif
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code wasn't quite right. The value for arm64 dwarf is 0x03000000. However even with that fixed the linker was reporting compact unwind errors.

The comments in the Apple compact unwind header suggests the linker will no longer attempt to create compact unwind entries from dwarf tables. Specifically because they found it was too fragile.

I chose to remove this so that the linker was forced to use the dwarf unwind info for these hand coded assembly files.

w/o this change the linker reportes errors related to overlapping __compact_unwind entries as well as corrupt size.

IMHO this seems reasonable....

@mangod9
Copy link
Member

mangod9 commented Aug 6, 2020

nice progress @sdmaclea. Great that things are now building.

@mangod9 mangod9 added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Aug 6, 2020
@sdmaclea
Copy link
Contributor Author

I have started a new Priority1 test run on Apple Silicon using tests and runtime built on osx-arm64. It looks like the cross built code is working properly. Thanks @janvorli.

This should be really close to passing CI. We should be able to merge this soon.

The W^X code is known to be preliminary. We intend to refactor in a later PR for

  • W^X support on other platforms
  • Better locality. Keep the enable of writing closer to the code which does the writing.

@janvorli Can you please take another look?

eng/native/configureplatform.cmake Outdated Show resolved Hide resolved
eng/build.sh Show resolved Hide resolved
if(convert)
{
int nsize;
LPSTR newBuff = 0;
nsize = WideCharToMultiByte(CP_ACP, 0,(LPCWSTR)buffer, count, 0, 0, 0, 0);
if (!nsize)
{
if (count == 0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still wonder why this occurs for arm64 OSX only and it was fine before.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't remember the test which caught this issue. I looked at the call stack briefly and it looked like a bogus failure to me. This looked like the right fix.

I opened #42954. To investigate this further when we have more capacity for testing on Apple Silicon.

// TBD // Inject the activation only if the thread doesn't have a pending hardware exception
// Inject the activation only if the last ESR.EC was an SVC and therefore the thread doesn't have
// a pending hardware exception
if ((ExceptionState.__esr >> 26) == 0x15)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please make these named constants or defines to make it clear?
E.g. ESR_EC_SHIFT for the 26 and EC_SVC for 0x15 or something like that.

src/coreclr/src/vm/arm64/stubs.cpp Outdated Show resolved Hide resolved
@@ -3312,6 +3312,10 @@ DWORD_PTR ExceptionTracker::CallHandler(
break;
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not clear to me why we need it here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would guess it is related to the MakeCallbacksRelatedToHandler() call below which can call managed code. I am not sure why I didn't place it above the MakeCallbacksRelatedToHandler() call above, but perhaps we simply didn't have coverage of that case.

It is probably not the right place to put this ultimately, but it is related to the arbitrary nature of the current PAL_JITWriteEnable(*) placement.

I would suggest leaving this to be cleaned up by #41124

@@ -3948,6 +3952,10 @@ void ExceptionTracker::ResumeExecution(
EH_LOG((LL_INFO100, "resuming execution at 0x%p\n", GetIP(pContextRecord)));
EH_LOG((LL_INFO100, "^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n"));

#if defined(HOST_OSX) && defined(HOST_ARM64)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And I would like to understand why we need it here either.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this might have been added to fix a case where we were trying to JIT a method which didn't exist (probably a dynamic method builder test). Effectively the pre*stub threw an exception and the exception handler required us to return to managed code in the managed exception handler.

So this too is introduced by the ad-hoc placement of the PAL_JITWriteEnable(*) calls.

I would suggest leaving this to be cleaned up by #41124.

src/coreclr/src/vm/gcinfodecoder.cpp Outdated Show resolved Hide resolved
@sdmaclea
Copy link
Contributor Author

sdmaclea commented Oct 1, 2020

@janvorli I believe I have addressed your comments either directly or by opening issues to be solved later.

@sdmaclea
Copy link
Contributor Author

sdmaclea commented Oct 6, 2020

@janvorli The previous commit was green. The most recent commit doesn't touch code currently compiled in CI.
Please take a look again. I would like to merge this as is and iterate in future PRs.

Copy link
Member

@janvorli janvorli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current state LGTM modulo the two comments. But I'd like to get a review of @jkotas now that the change is final.

src/coreclr/src/pal/src/exception/machexception.cpp Outdated Show resolved Hide resolved
int main()
{
int ret;
ret = clock_gettime_nsec_np(CLOCK_UPTIME_RAW);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious - what was wrong with mach_absolute_time ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't exist on aarch64 and Apple doc for mach_absolute_time recommends to replace it with clock_gettime_nsec_np

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have noticed that HAVE_MACH_ABSOLUTE_TIME is still used under libraries. Do we need to fix it there as well?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, the strange thing is that libraries compile for arm64 with it just fine. So maybe the failure due to which I've modified the usage of mach_absolute_time to clock_gettime_nsec_np was something temporary in the middle of the fixes I was making. Anyways, the change is good since the mach_absolute_time is deprecated, so we should change it in the libraries too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, opened #43320

@janvorli janvorli closed this Oct 6, 2020
@janvorli janvorli reopened this Oct 6, 2020
Copy link
Member

@jkotas jkotas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGMT

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support Runtime native build on Apple arm64.
5 participants